Configuring Registration Accounts

The Accounts table lets you configure up to 288 Accounts. An Account defines information for registering and authenticating (digest) Trunk Groups (e.g., PBX) or IP Groups (e.g., IP PBX) with a "serving" IP Group (e.g., ITSP).

The device initiates registration with a "serving" IP Group on behalf of the "served" Trunk Group or IP Group. Therefore, Accounts are typically required when the "served" Trunk Group or IP Group is unable to register or authenticate itself for whatever reason. Registration information includes username, password, host name (AOR), and contact user name (AOR). The device includes this information in the REGISTER message sent to the serving IP Group. Up to 10 Accounts can be configured per "served" Trunk Group or IP Group. A Trunk Group or IP Group can register to more than one IP Group (e.g., multiple ITSPs). This is done by configuring multiple entries in the Accounts table for the same served Trunk Group or IP Group, but with different serving IP Groups, username/password, host name, and contact user values.

You cannot configure more than one Account with the same "served" Trunk Group or IP Group and "serving" IP Group combination. For example, only one Account can be configured with the 'Served IP Group' parameter set to "Users-Boston" and the 'Serving IP Group' parameter set to "ITSP".

Authentication is typically required for INVITE messages sent to the "serving" IP Group. If the device receives a SIP 401 (Unauthorized) in response to a sent INVITE, the device checks for a matching "serving" and "served" entry in the Accounts table. If a matching row exists, the device authenticates the INVITE by providing the corresponding MD5 authentication username and password to the "serving" IP Group.

If the Account is not registered and the device receives a SIP dialog request (e.g., INVITE) from the Served IP Group, the device rejects the dialog and sends the Served IP Group a SIP 400 (Bad Request) response. An Account that is not registered can be due to any of the following reasons:

■ You have unregistered the Served IP Group by clicking the Register button (discussed later in this section).
■ The Serving IP Group has rejected the registration.

However, if the Account is not registered and you have enabled the Registrar Stickiness feature ('Registrar Stickiness' parameter is configured to Enable) or dynamic UDP port assignment feature ('UDP Port Assignment' parameter is configured to Enable) and the device receives a SIP dialog request (e.g., INVITE) from the Served IP Group, the device rejects the dialog and sends the Served IP Group a SIP 500 (Server Internal Error) response. In this scenario, the Account can be not registered due to any of the reasons listed previously or for the dynamic UDP port assignment feature, there is no available port for the Account (port used for interfacing with the Serving IP Group).

● Gateway application: If no match is found in the Accounts table for incoming or outgoing calls, the username and password is taken from:
✔ For FXS interfaces: Authentication table (see Configuring Authentication per PortConfiguring Authentication)
✔ 'UserName' and 'Password' parameters on the Proxy & Registration page
● SBC application: The device uses the username ('Username As Client' parameter) and password ('Password As Client' parameter) that are configured for the Serving IP Group in the IP Groups table, for user registration and authentication, in the scenarios listed below. For this mode of operation, configure the device to authenticate as a client (i.e., 'Authentication Mode' parameter in the IP Groups table for the Serving IP Group is SBC As Client or SBC as Both Client and Server).
✔ If there is no Account configured for the Served IP Group and Serving IP Group in the Accounts table.
✔ If there is an Account configured for the Served IP Group and Serving IP Group, but without a username and password.
● See also the following optional, related parameters:
✔ [UseRandomUser] - enables the device to assign a random string to the user part of the SIP Contact header of new Accounts.
✔ [UnregisterOnStartup] - enables the device to unregister and then re-register Accounts upon a device restart.
✔ [RegistrationSyncMode] - enables synchronization of all Accounts (and users in the SBC User Information table - Configuring SBC User Information Table through Web Interface) that register to the same proxy server (Serving IP Group). Upon registration failure (timeout or failure response), only the Account (or SBC User Info user) that first detected the failure, continues its attempt at registering (sending REGISTER requests) to the proxy. For more information, see the parameter's description.
● Gateway application: If all trunks belonging to the Trunk Group are down, the device un-registers them. If any trunk belonging to the Trunk Group returns to service, the device registers them again. This ensures, for example, that the Proxy doesn't send SIP INVITE messages to trunks that are out of service.

The following procedure describes how to configure Accounts through the Web interface. You can also configure it through ini file [Account] or CLI (configure voip > sip-definition account).

➢ To configure an Account:
1. Open the Accounts table (Setup menu > Signaling & Media tab > SIP Definitions folder > Accounts).
2. Click New; the following dialog box appears:

3. Configure an account according to the parameters described in the table below.
4. Click Apply.

Once you have configured Accounts, you can register or un-register them, as described below:

➢ To register or un-register an Account:
1. In the table, select the required Account entry row.
2. From the Action drop-down list, choose one of the following commands:
● Register to register the Account.
● Un-Register to un-register the Account.

Accounts Table Parameter Descriptions

Parameter

Description
General

'Index'

Defines an index for the new table row.

Note: Each row must be configured with a unique index.

'Name'

account-name

[Account_AccountName]

Defines an arbitrary name to easily identify the row.

The valid value is a string of up to 20 characters.

Note: Configure each row with a unique name.

'Served Trunk Group'

served-trunk-group

[Account_ServedTrunkGroup]

Defines the Trunk Group that you want to register and/or authenticate.

■ For Tel-to-IP calls, the served Trunk Group is the source Trunk Group from where the call originated.
■ For IP-to-Tel calls, the served Trunk Group is the Trunk Group to where the call is sent.

Note: The parameter is applicable only to the Gateway application.

'Application Type'

application-type

[Account_ApplicationType]

Defines the application type:

■ [0] GW = (Default) Gateway application.
■ [2] SBC = SBC application.

'Served IP Group'

served-ip-group-name

[Account_ServedIPGroupName]

Defines the IP Group (e.g., IP-PBX) that you want to register and/or authenticate upon its behalf.

Note:

■ The parameter is applicable only to the SBC application.
■ By default, all IP Groups are displayed. However, if you filter the Web display by SRD (using the SRD Filter box), only IP Groups associated with the filtered SRD are displayed.
■ You can configure up to 10 Accounts per IP Group.
■ The parameter is mandatory.

'Serving IP Group'

serving-ip-group-name

[Account_ServingIPGroupName]

Defines the IP Group (Serving IP Group) to where the device sends the SIP REGISTER requests (if enabled) for registration and authentication (of the Served IP Group).

For the Gateway application:

■ Tel-to-IP calls: The serving IP Group is the destination IP Group configured in the Trunk Group Settings table or Tel-to-IP Routing table (see Configuring Tel-to-IP Routing Rules).
■ IP-to-Tel calls: The serving IP Group is the 'Source IP Group ID' configured in the IP-to-Tel Routing table (see Configuring IP-to-Tel Routing Rules).

Note:

■ By default, only IP Groups associated with the SRD to which the Served IP Group is associated are displayed, as well as IP Groups of Shared SRDs. However, if you filter the Web display by SRD (using the SRD Filter box), only IP Groups associated with the filtered SRD are displayed, as well as IP Groups of Shared SRDs.
■ (Gateway application only) If the Serving IP Group is associated with Proxy Set #0, you must configure the [IsProxyUsed] parameter to [1].
■ The parameter is mandatory.

'Host Name'

host-name

[Account_HostName]

Defines the Address of Record (AOR) host name. The host name appears in SIP REGISTER From/To headers as ContactUser@HostName. For a successful registration, the host name is also included in the URI of the INVITE From header.

The valid value is a string of up to 49 characters.

Note: If the parameter is not configured or if registration fails, the 'SIP Group Name' parameter value configured in the IP Groups table is used instead.

'Contact User'

contact-user

[Account_ContactUser]

Defines the AOR username. This appears in SIP REGISTER From/To headers as ContactUser@HostName, and in INVITE/200 OK Contact headers as ContactUser@<device's IP address>.

The valid value is a string of up to 60 characters. By default, no value is defined.

Note:

■ If the parameter is not configured, the 'Contact User' parameter in the IP Groups table is used instead.
■ If registration is disabled for the Account, or registration fails, the user part in the SIP INVITE's Contact header contains the source party number.
■ If the source of the message is a registered user or matches a record in the SBC User Information table (see Configuring SBC User Information Table through Web Interface), it has higher priority than the Account's configuration in deciding the user part in the INVITE's Contact header.

'Register'

register

[Account_Register]

Enables registration.

■ [0] No = (Default) The device only performs authentication (not registration). Authentication is typically done for INVITE messages sent to the "serving" IP Group. If the device receives a SIP 401 (Unauthorized) in response to a sent INVITE, the device checks for a matching "serving" and "served" entry in the table. If a matching row exists, the device authenticates the INVITE by providing the corresponding MD5 authentication username and password to the "serving" IP Group.
■ [1] Regular = The device performs regular registration. For more information, see Regular Registration Mode.
■ [2] GIN = The device performs registration for legacy PBXs, using Global Identification Number (GIN). For more information, see Single Registration for Multiple Phone Numbers using GIN.

Note:

■ Gateway application: To enable registration, you also need to configure the 'Registration Mode' parameter to Per Account in the Trunk Group Settings table (see Configuring Trunk Group Settings).
■ Account registration is not affected by the [IsRegisterNeeded] parameter.

'Registrar Stickiness'

registrar-stickiness

[Account_RegistrarStickiness]

Enables the Registrar Stickiness feature.

■ [0] Disable = (Default) Disables the Registrar Stickiness feature. After a successful initial registration of the Account with a registrar (IP address), whenever the device receives a SIP request or registration refresh, the device sends the request to whichever IP address is the currently working registrar. In other words, there is no binding to a specific IP address in the Proxy Set and at any given time, requests may be sent to a different IP address, whichever is the working one. In the case of proxy load-balancing, there is no certainty as to which IP address in the Proxy Set the request is routed.
■ [1] Enable = Enables the Register Stickiness feature. The device always routes SIP requests of a registered Account to the same registrar server to where the last successful REGISTER request was routed. In other words, once initial registration of the Account to one of the IP addresses in the Proxy Set (associated with the Account's Serving IP Group) is successful (i.e., 200 OK), binding ("stickiness") occurs to this specific address (registrar). All future SIP requests (e.g., INVITEs, SUBSCRIBEs and REGISTER refreshes) whose source and destination match the Account are sent to this registrar only. This applies until the registrar is unreachable or registration refresh fails, for whatever reason
■ [2] Enable for Non-REGISTER Requests = Enables the Register Stickiness feature, as described for the Enable option (above), except for refresh REGISTER messages. When the device initiates a refresh REGISTER message for the Account, it restarts the registration process for the Account, sending the message to one of the registrar servers according to the Proxy Set of the Account's Serving IP Group. This option can used, for example, in scenarios where proxy keep-alive is disabled (see the 'Proxy Keep-Alive' parameter in the Proxy Sets table) and restart of registration for refresh REGISTERs is always preferred.

Note:

■ The parameter is applicable only if you have enabled Account registration ('Register' parameter configured to Regular or GIN).
■ If an Account is registered with a registrar server which the device no longer "knows" (e.g., it was removed from the IP address results of the DNS resolution for the related Proxy Set) and the Registrar Stickiness feature is enabled, the device immediately initiates a new registration process for the Account (toward a different server of the Proxy Set).

'Registrar Search Mode'

registrar-search-mode

[Account_RegistrarSearchMode]

Defines the method for choosing an IP address (registrar) in the Proxy Set (associated with the Serving IP Group) to which the Account initially registers and performs registration refreshes, when the Register Stickiness feature is enabled. Once chosen, the Account is binded to the IP address for subsequent SIP requests.

■ [0] Current Working Server = (Default) For each initial and refresh registration request, the device routes to the currently working server in the list of IP addresses (configured or DNS-resolved IP addresses) in the Proxy Set. In the case of proxy load-balancing, the chosen IP address is according to the load-balancing mechanism.
■ [1] According to IMS Specifications = For the initial registration request, the device performs DNS resolution if the address of the Proxy Set is configured as an FQDN. It then attempts to register to one of the listed DNS-resolved addresses (or configured IP addresses), starting with the first listed address and then going down the list sequentially. If an address results in an unsuccessful registration, the device immediately tries the next address (without waiting any retry timeout). The device goes through the list of addresses until an address results in a successful registration. If registration is unsuccessful for all addresses, the device waits a configured retry time and then goes through the list again. Once initial registration is successful, periodic registration refreshes are performed as usual. In addition to the periodic refreshes, immediate register refreshes are done upon the following triggers according to the IMS specification:
✔ The device receives a SIP 408, 480, or 403 response from the Serving IP Group in response to an INVITE.
✔ The transaction timeout expires for an INVITE sent to the Serving IP Group.
✔ The device receives an INVITE from the Serving IP Group from an IP address other than the address to which it is currently registered. In this case, it also rejects the INVITE with a SIP 480 response.

If the device's physical Ethernet link to the proxy goes down, the device re-registers this Account with the proxy when the link comes up again. Re-registration occurs even if proxy keep-alive is disabled.

Note: This option is applicable only if you have configured the following:

✔ 'Register' parameter to Regular or GIN.
✔ 'Registrar Stickiness' parameter to Enable.
■ [2] Avoid Previous Registrar Until Expiry = This option prevents the device from sending REGISTER requests to a registrar server where the device previously registered, if the device also registered successfully to another server since the last successful registration to the registrar server. This can occur if the registrar server has been offline for a brief time. The device avoids attempting to register to this registrar server for a duration that is calculated according to the cumulative value of the Proxy Server's last 'Expires' time and the grace time configured by the [AccountRegistrarAvoidanceTime] global parameter.

Note:

✔ The value of the SIP Expires header in some REGISTER requests sent by the device may be less than the configured registration time (configured by [RegistrationTime]), when this option is used. The aim is to return registration to the higher priority server, soon after the avoidance time passes.
✔ When this option is used, the Proxy Set of the Account’s 'Serving IP Group' can have a maximum of three proxies (IP addresses may be resolved from a single Proxy host name).
✔ Proxy Hot Swap isn’t supported when this option is used.

For example: Assume the Account is configured with 'Registrar Search Mode' set to Avoid Previous Registrar Until Expiry and the global parameter [AccountRegistrarAvoidanceTime] set to 180 seconds (3 minutes). In addition, the Account's 'Serving IP Group' uses a Proxy Set with three proxy server IPs (X, Y, Z; each proxy has a different priority) and uses the Homing mode.

The following describes the timeline sequence of events:

a. At 12:00:00, the Account successfully registers to server X; the 200 OK received from server X includes an expiry time of 8 minutes (Expires: 480 seconds).
b. At 12:01:00, the device recognizes that server X is offline (using keep-alive with OPTIONS on the Proxy Set).
c. When the device needs to send the next REGISTER request (by default, after half of the registration Expires time, i.e. 4 minutes, at 12:04:00), the device registers to server Y.
d. At 12:05:00, the device recognizes that server X is back online. Even though server X has a higher priority than server Y, the device doesn't re-register to server X (instead, it registers to server Y) until after 12:11:00. Since the last successful registration to server X occurred at 12:00:00, the device only re-register to server X after 12:11:00 (i.e., Expires = 8 minutes + AccountRegistrarAvoidanceTime which is 3 minutes (180 seconds). In this way, the device avoids sending REGISTER requests to the previous (non-current) registrar.

'Re-REGISTER on INVITE Failure'

re-register-on-invite-failure

[Account_ReRegisterOnInviteFailure]

Enables the device to re-register an Account upon the receipt of specific SIP response codes (e.g., 403, 408, and 480) for a failed INVITE message sent to the Serving IP Group.

■ [0] Disable = (Default) If the device receives a SIP response for a failed INVITE message, the device doesn't re-register the Account.
■ [1] Enable = If the device receives a SIP response for a failed INVITE message and the response code is configured in the global parameter, AccountInviteFailureTriggerCodes, the device re-registers the Account according to the settings of the Proxy Set associated with the Account's Serving IP Group. Note that if the Proxy Set’s 'Proxy Hot Swap Mode' parameter is configured to Enable and the 'Proxy Keep-Alive' parameter to Using OPTIONS, Using OPTIONS on Active Server, or Using REGISTER, then the registrar at which the INVITE failed is tried last in the list of servers in the Proxy Set.

'Reg Event Package Subscription'

reg-event-package-subscription

[Account_RegEventPackageSubscription]

Enables the device to subscribe to the registration event package service (as defined in RFC 3680) with the registrar server (Serving IP Group) to which the Account is successfully registered and binded, when the Registrar Stickiness feature is enabled. The service allows the device to receive notifications of the Accounts registration state change with the registrar.

The device subscribes to the service by sending a SUBSCRIBE message containing the Event header with the value "reg" (Event: reg). Whenever a change occurs in the registration binding state, the registrar notifies the device by sending a SIP NOTIFY message.

■ [0] Disable (default)
■ [1] Enable

Note: The parameter is applicable only if you have enabled the Registrar Stickiness feature (in this table):

■ 'Register' parameter to Regular or GIN.
■ 'Registrar Stickiness' parameter to Enable.

'Register by Served IP Group Status'

reg-by-served-ipg-status

[Account_RegByServedIPG]

Defines the device's handling of Account registration based on the connectivity status of the Served IP Group.

■ [0] Register Always = (Default) Account registration by the device doesn't depend on the connectivity status of the Served IP Group. The device sends registration requests to the Serving IP Group even if the Served IP Group is offline.
■ [1] Register Only if Online = The device performs Account registration depending on the connectivity status of the Served IP Group. It sends a registration request to the Serving IP Group only if the Served IP Group is online. If the Served IP Group was registered, but then goes offline, the device unregisters it. If it becomes online again, the device re-registers it. This option is applicable only to Accounts where registration is initiated by the device (i.e., the 'Register' parameter is configured to any value other than No).

The Served IP Group's connectivity status is determined by the keep-alive mechanism of its associated Proxy Set (i.e., the 'Proxy Keep-Alive' parameter is configured to Using OPTIONS, Using OPTIONS on Active Server or Using Fake REGISTER).

Note: The parameter is applicable only to the SBC application.

'UDP Port Assignment'

udp-port-assignment

[Account_UDPPortAssignment]

Enables the device to dynamically allocate local SIP UDP ports to Accounts using the same Serving IP Group, where each Account is assigned a unique port on the device's leg interfacing with the Accounts' Serving IP Group.

■ [0] Disable = (Default) The device uses the same specific UDP port for all registrations done for this Account (traffic between the device and the Serving IP Group). This port is the one configured for the SIP Interface ('UDP Port' parameter) that is associated with the Proxy Set of the Account's Serving IP Group.
■ [1] Enable = The device assigns a unique local port for each Account for which the device initiates registration. The port is taken from a configured UDP port range. The port range is configured for the SIP Interface ('Additional UDP Ports' parameter) associated with the Proxy Set of the Account's Serving IP Group. Traffic between the Serving IP Group and device is sent from and received on the assigned unique local port. If enabled for other Accounts that are configured with the same Serving IP Group, each Account is allocated a unique UDP port from the port range. For example, if you have configured two Accounts, "PBX-1" and "PBX-2", the device could assign port 6000 to "PBX-1" and 6100 to "PBX-2".

Note:

■ The parameter is applicable only to the SBC application.
■ If you enable the parameter, you must also enable the device to initiate registration for the Account (i.e., configure the 'Register' parameter to any value other than No).
■ If the device fails to allocate a port (e.g., insufficient ports), the device doesn't send the SIP REGISTER request, but tries again within a period configured by the RegistrationRetryTime and MaxRegistrationBackoffTime parameters.
■ If the device receives a SIP request from the Serving IP Group for the Account, on a port that was not assigned to the Account, it rejects the request (with a SIP 404 Not Found response).
■ If the device receives a SIP request from the Served IP Group and the Account has not been allocated a valid port, the device rejects the request (with a SIP 500 Server Internal Error response).
■ For more information on configuring the SIP Interface's port range, see Configuring SIP Interfaces.

'Account Registration Status'

(Read-only field) Displays the registration status of the Account ("Registered" or "Not Registered").

You can also view Account registration status on the Registration Status page (see Viewing Registration Status).

Credentials

'User Name'

user-name

[Account_Username]

Defines the digest MD5 Authentication username.

The valid value is a string of up to 60 characters. By default, no value is defined.

'Password'

password

[Account_Password]

Defines the digest MD5 Authentication password.

The valid value is a string of up to 50 characters.

Note:

■ The password can't be configured with wide characters.
■ If the password contains a question mark (?) and you're configuring the parameter through CLI, you must enclose the entire password in double quotation marks (e.g., "43LSyk+?").